In today's complex and everchanging digital world physical prototyping has become a de-facto industry standard during the development of Application Specific Integrated Circuit (ASIC) designs and System-on-Chip (SoC) designs (collectively referred to herein as circuit designs) to assure first-pass silicon success during subsequent fabrication on silicon. Physical prototyping involves constructing a prototype circuit/system in which one or more programmable logic devices (PLDs; e.g., field programmable gate arrays (FPGAs), programmable logic arrays (PLAs) and programmable array logic (PALs)) and zero or more component devices are operably configured to produce a physical implementation of the circuit design, thereby allowing the circuit designers to verify that a physical device implementing the IC meets established functional requirements. The importance of prototyping has increased because minimizing both time-to-market and cost-to-reach-market have never been more important to the commercial success of modern IC devices, and because generating and testing a physical prototype that implements a circuit design requires substantially less time and expense than generating and testing a fabricated ASIC or SoC “chip” that implements the circuit design. That is, by prototyping a circuit design before submitting the circuit design to a fabrication facility for generation as ASIC, flaws in the circuit design that were not detected during simulation can be identified and corrected with substantially less time and expense. Moreover, physical prototyping enables rapid verification and validation of any last-minute modifications to the final circuit design by way of reconfiguring the PLD(s) that implement the circuit design.
A problem recently encountered with physical prototyping involves validation of circuit designs requiring data transmission speeds/rates that are greater than those supported by the PLDs utilized in an established prototype hardware platform. That is, the operating speed of a given PLD is inherently slower than a corresponding ASIC due to the programmable switches that facilitate the reconfigurability of the PLD. This puts an additional challenge on PLD-based physical prototype platforms when tasked to implement circuit designs requiring high speed data transmissions because such circuit designs are typically generated for a specific ASIC fabrication technology that supports the higher speeds; i.e., when such circuit designs are implemented in slower PLDs, timing specifications (e.g., controller timing requirements) established in the ASIC-targeted circuit design code cannot be validated using the PLD-based prototype platform. Note that it is not easy to change the timing requirements to meet prototyping needs, for example, to verify timing closure of the circuit design when implemented in a PLD that cannot support the higher speed/timing requirements. Moreover, changing or upgrading a target PLD to meet higher speed requirements would be expensive in terms of both time and cost as this approach would require the design and bring-up of a new prototype hardware platform.
The above-mentioned problem associated with established PLD-based prototype platforms is particularly relevant to circuit designs that implement JEDEC Universal Flash Storage (UFS) protocols. The UFS protocol has become the mobile storage standard of choice for today's high-end smartphones, tablets and cameras, mainly due to its performance and high bandwidth over other existing solutions. These advantages have become critical to meet end users' requirements for higher responsiveness and increased capabilities. For example, end users expect to transmit and receive their high-resolution photos and videos in seconds amid the high volume of files and other operations, and currently only the UFS protocol meets these expectations. To implement the UFS protocol, a circuit design typically includes a UFS host controller operably connected to an MIPI M-PHY interface layer in the manner depicted in FIG. 8. In particular, the UFS controller is typically implemented using a UniPro IP/standard cell to provide a data transmission (or link) layer along with the additional circuitry depicted in FIG. 8, a MIPI M-PHY (specification standard cell) to provide a physical interconnect layer, and a standard Reference M-PHY Module Interface (RMMI) to provide data and control signal transmissions between the UFS controller and the M-PHY. MIPI M-PHY would support High-Speed Gear 4 in Version 4.1 and so MIPI UniPro has come up with High Speed Gear 4 specification in Version 1.8. UFS would leverage on both link and physical layers to achieve high speed data transfer. In this document, references to UFS host controller are intended to reference the various components included in FIG. 8, including a UniPro link layer (e.g., UniPro Layer V1.8 or higher), as well as operable connection to a standard RMMI interface between UFS host controller and MIPI M-PHY 4.0 or 4.1.
FIG. 9 depicts an exemplary conventional prototype platform 50 made up of a host printed circuit board (PCB) 51-1 and a device PCB 51-2 are operably connected to each other and to a PC system 59. A programmable logic device (PLD) 52-1 is mounted on PCB 51-1 and is configured to implement a host circuit design 53-1 along with a UFS controller 54-1 of an ASIC-targeted or SoC-targeted circuit design, and standard test circuitry 54-1 (e.g., a PC-input/output cell) that facilitates communication with PC system 59. An M-PHY physical interface device (M-PHY PID) 55-1 is mounted on a daughter card that is attached to PCB 51-1 and connected to UFS controller 54-1 by way of a 40-bit RMMI bus 56-1. Device PCB is similarly composed with a PLD 52-2 configured to implement a device design 53-2, a second UFS controller 54-2 and test circuitry 54-2, with a second M-PHY PID 55-2 mounted thereon and connected to UFS controller 54-2 by way of a 40-bit RMMI bus 56-2. PC system 59 may be configured to mimic and perform data traffic exchanges between the host and device.
A problem with prototype system 50 is that this arrangement requires direct transmission of M-PHY generated clock signals at speeds that cannot be supported by the PLD-implemented UFS controller. That is, the transmission speed of data from UFS controller 54-2 to M-PHY PID 55-2 over RMMI bus 56-2 during data transmission operations is controlled by a clock signal Tx_SymbolClk, and the transmission speed of data from M-PHY PID 55-2 to UFS controller 54-2 over RMMI bus 56-2 during data reception operations is controlled by clock signal Rx_SymbolClk, where both Tx_SymbolClk and Rx_SymbolClk are generated by the M-PHY circuitry. In order to perform 11.6 Gigabit-per-second (Gbps) HS-G4 data transmissions over signal lines 58 using this conventional prototype platform the M-PHY circuitry must generate the Tx_SymbolClk and Rx_SymbolClk at 292 MHz (i.e., each of the 40 lines forming RMMI bus 55-1 must carry data at 292 MHz). This means that the UniPro layer IP of UFS controller 54-1 must operate at a speed that meets the 292 MHz frequency requirement, which cannot be supported by many existing PLD-based prototype platforms. Moreover, addressing this problem by increasing the RMMI interface width (e.g., by way of increasing the transmission/reception channels of RMMI buses 56-1 and 56-2 from 40-bits to 80-bits) to reduce the speed requirements on the UFS controllers is not practical because this would require significant changes to the ASIC-targeted circuit design code, and would also double the number of required PLD output pins (i.e., PLD 51-1 and 51-2 may not have sufficient available I/O pins to support this solution).
What is needed is a cost-effective physical prototyping approach that facilitates validating the functionality of a circuit design at operating speeds that exceed the capabilities of a prototype platform's component PLDs. What is particularly needed is a prototyping approach that facilitates validating controller timing requirements during UFS HS-G4 data transmissions without requiring modification of the ASIC-targeted circuit design code.